👣👣👣
CoinJoin, CoinShuffle и Stealth-Addresses - Сегодня разбираемся с протоколами анонимности!
⬇️⬇️⬇️
https://telegra.ph/CoinJoin-CoinShuffle-i-Stealth-Addresses---Razbiraemsya-s-anonimnostyu-03-13
#Privacy
CoinJoin, CoinShuffle и Stealth-Addresses - Сегодня разбираемся с протоколами анонимности!
⬇️⬇️⬇️
https://telegra.ph/CoinJoin-CoinShuffle-i-Stealth-Addresses---Razbiraemsya-s-anonimnostyu-03-13
#Privacy
Telegraph
CoinJoin, CoinShuffle и Stealth-Addresses - Разбираемся с анонимностью
CoinJoin CoinJoin — это протокол, который усиливает конфиденциальность транзакций биткоина. С его помощью несколько сторон могут отправлять средства в рамках одной транзакции без риска кражи. Был впервые предложен в 2013 году. Протокол CoinJoin позволяет…
✅✅✅
Протокол блокчейна MimbleWimble
⬇️⬇️⬇️
MimbleWimble – это протокол блокчейна, который обеспечивает анонимность и масштабируемость, проверяя, что все транзакции действительны без необходимости хранить всю историю цепи.
Название MimbleWimble взято из книги о Гарри Поттере...в криптотусовке любят такие штуки😄
Немного истории:
Первоначально протокол был предложен в 2016 году, автором «Tom Elvis Jedusor» (французское имя Волан-де-Морта из серии книг о Гарри Поттере). Предложение вызвало интерес у криптосообщества, а оригинальная техническая документация была позже усовершенствована.
White paper Тома "Mimblewimble" было предложением блокчейна, которое чисто теоретически должно увеличить конфиденциальность, масштабируемость и взаимозаменяемость.
В том же 2016 году Ignotus Peverell (первый владелец плаща-невидимки) начал проект в Github под названием «Grin», и начал превращать реализовывать MimbleWimble.
Принцип работы
Основная архитектура MimbleWimble взята у Биткоина, исключая сценарии но с добавлением конфиденциальных транзакций и концепции сквозных переводов. В результате получился поддающийся сжатию и непрозрачный блокчейн.
В протоколе MimbleWimble никакая информация о какой-либо транзакции не доступна третьим лицам, которые не участвовали бы в транзакции. Протокол MimbleWimble при каждой транзакции проверяет, что новые монеты не создаются и что стороны, осуществляющие операции, подтвердили право собственности на свои приватные ключи.
Предполагалось, что MimbleWimble может быть интегрирован в кодовую базу биткоина через софтфорк или существовать в виде сайдчейна, но позже это вылилось в определенные сложности.
Отсутствие языка написания сценариев (языка скриптов) в MimbleWimble означает, что не остается пространства для таких инноваций, как, например, платежные каналы (Lightning Network) и межплатформенные атомарные свопы, которые уже запущены в сети биткоина.
Особенностью MimbleWimble является возможность создания иной структуры транзакций и меньшего по размеру блокчейна, чем биткоина.
В MimbleWimble нет привычных пользователям биткоина адресов — вместо этого два кошелька обмениваются данными друг с другом. Эти данные видны только участникам транзакции, при этом им даже не обязательно находиться в онлайне одновременно. Блоки не перечисляют отдельные транзакции, а объединяются в одну транзакцию со смешанными входами и выходами. Таким образом просмотр одного блока не даст информации об отдельно взятых транзакциях.
Концепция MimbleWimble использует тот же метод эллиптических кривых при подписи транзакций, что лежит в основе биткоина.
Просмотр одного блока не даст информации об отдельно взятых транзакциях. По факту транзакции в MimbleWimble являются вариантом техники микширования монет CoinJoin.
Сейчас протокол рассматривается как сайдчейн Биткоина или в виде отдельного блокчейна, использующего собственный протокол консенсуса (возможно, через объединенный майнинг), но не собственный токен. Вместо этого, в нем может использоваться валюта Биткоина через двустороннюю привязку.
Разработчики пришли к выводу, что лучшим решением будет создание отдельной монеты, и с момента презентации протокола появились две его имплементации, каждая из них придерживается различных подходов к сообществу, философии, финансированию и техническим спецификациям: Grin и Beam
Имплементации протокола MimbleWimble: Grin и Beam
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/808
Bitcoin Sunset Grin Sunrise (перевод)
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/886
#Privacy
Протокол блокчейна MimbleWimble
⬇️⬇️⬇️
MimbleWimble – это протокол блокчейна, который обеспечивает анонимность и масштабируемость, проверяя, что все транзакции действительны без необходимости хранить всю историю цепи.
Название MimbleWimble взято из книги о Гарри Поттере...в криптотусовке любят такие штуки😄
Немного истории:
Первоначально протокол был предложен в 2016 году, автором «Tom Elvis Jedusor» (французское имя Волан-де-Морта из серии книг о Гарри Поттере). Предложение вызвало интерес у криптосообщества, а оригинальная техническая документация была позже усовершенствована.
White paper Тома "Mimblewimble" было предложением блокчейна, которое чисто теоретически должно увеличить конфиденциальность, масштабируемость и взаимозаменяемость.
В том же 2016 году Ignotus Peverell (первый владелец плаща-невидимки) начал проект в Github под названием «Grin», и начал превращать реализовывать MimbleWimble.
Принцип работы
Основная архитектура MimbleWimble взята у Биткоина, исключая сценарии но с добавлением конфиденциальных транзакций и концепции сквозных переводов. В результате получился поддающийся сжатию и непрозрачный блокчейн.
В протоколе MimbleWimble никакая информация о какой-либо транзакции не доступна третьим лицам, которые не участвовали бы в транзакции. Протокол MimbleWimble при каждой транзакции проверяет, что новые монеты не создаются и что стороны, осуществляющие операции, подтвердили право собственности на свои приватные ключи.
Предполагалось, что MimbleWimble может быть интегрирован в кодовую базу биткоина через софтфорк или существовать в виде сайдчейна, но позже это вылилось в определенные сложности.
Отсутствие языка написания сценариев (языка скриптов) в MimbleWimble означает, что не остается пространства для таких инноваций, как, например, платежные каналы (Lightning Network) и межплатформенные атомарные свопы, которые уже запущены в сети биткоина.
Особенностью MimbleWimble является возможность создания иной структуры транзакций и меньшего по размеру блокчейна, чем биткоина.
В MimbleWimble нет привычных пользователям биткоина адресов — вместо этого два кошелька обмениваются данными друг с другом. Эти данные видны только участникам транзакции, при этом им даже не обязательно находиться в онлайне одновременно. Блоки не перечисляют отдельные транзакции, а объединяются в одну транзакцию со смешанными входами и выходами. Таким образом просмотр одного блока не даст информации об отдельно взятых транзакциях.
Концепция MimbleWimble использует тот же метод эллиптических кривых при подписи транзакций, что лежит в основе биткоина.
Просмотр одного блока не даст информации об отдельно взятых транзакциях. По факту транзакции в MimbleWimble являются вариантом техники микширования монет CoinJoin.
Сейчас протокол рассматривается как сайдчейн Биткоина или в виде отдельного блокчейна, использующего собственный протокол консенсуса (возможно, через объединенный майнинг), но не собственный токен. Вместо этого, в нем может использоваться валюта Биткоина через двустороннюю привязку.
Разработчики пришли к выводу, что лучшим решением будет создание отдельной монеты, и с момента презентации протокола появились две его имплементации, каждая из них придерживается различных подходов к сообществу, философии, финансированию и техническим спецификациям: Grin и Beam
Имплементации протокола MimbleWimble: Grin и Beam
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/808
Bitcoin Sunset Grin Sunrise (перевод)
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/886
#Privacy
Telegram
CryptoBotan
👣👣👣
CoinJoin, CoinShuffle и Stealth-Addresses - Сегодня разбираемся с протоколами анонимности!
⬇️⬇️⬇️
https://telegra.ph/CoinJoin-CoinShuffle-i-Stealth-Addresses---Razbiraemsya-s-anonimnostyu-03-13
#Privacy
CoinJoin, CoinShuffle и Stealth-Addresses - Сегодня разбираемся с протоколами анонимности!
⬇️⬇️⬇️
https://telegra.ph/CoinJoin-CoinShuffle-i-Stealth-Addresses---Razbiraemsya-s-anonimnostyu-03-13
#Privacy
✅✅✅
Bulletproofs (BP)
В этом посте затрагивал механизм Bulletproofs. Я попытался коротко и понятно. На счет коротко - не получилось. На счет понятно - на ваше усмотрение😉
⬇️⬇️⬇️
Bulletproofs (BP) - это короткие неинтерактивные доказательства с нулевым разглашением (Zero-knowledge proof), которые не требуют доверенной установки.
Т.е. позволяет одной из взаимодействующих сторон («The verifier» — проверяющей) убедиться в достоверности какого-либо утверждения, не имея при этом никакой другой информации от второй стороны («The prover» — доказывающей).
BP используется для того, чтобы убедить верификатора в том, что зашифрованный текст верен.
Например, нужно доказать, что зашифрованное число находится в заданном диапазоне, не раскрывая больше ничего об этом числе.
Каждая конфиденциальная транзакция содержит криптографическое доказательство того, что транзакция действительна. BP доказательства уменьшают размер криптографического доказательства с более чем 10 Кб до менее чем 1 кб.
Если бы все транзакции биткойнов были конфиденциальными и использовали bulletproofs доказательства, то общий размер UTXO составил бы только 17 ГБ, по сравнению с 160 ГБ с используемыми в настоящее время.
Bulletproofs позволяет:
- уменьшить доказательство платежеспособности
Доказательство платежеспособности свидетельствует о том, что валютный контроль обеспечивает достаточные резервы для расчетов по счетам каждого клиента. Механизм сохраняет конфиденциальность доказательства платежеспособности, в соответствии с которыми биржа не обязана раскрывать свои биткойн-адреса, совокупные активы или обязательства, а также любую информацию о своих клиентах. Также оно не позволяет биржам вступать в сговор для покрытия убытков друг друга. Финику и К привет😄
- внедрить конфиденциальные смарт-контракты и в качестве общей замены Sigma-протоколов.
Sigma-протоколы разработаны для обеспечения надежного обмена криптографическими ключами при обеспечении различных функций. Sigma служит криптографической основой для подписей IKE- стандартизированного протокола обмена ключами в Интернете.
- Возможность "коротких проверяемых смешиваний" (short verifiable shuffles)
Суть в том, что имея два списка фиксированных значений, доказать, что второй список - это перестановка первого. Этот метод можно использовать в голосовании и доказательстве платежеспособности. Такая схема позволяет реализовывать перетасовку и сортировку двух списков и затем проверять, что они равны.
По своей эффективности технология сопоставляется с zk-SNARKs или zk-STARKs, но имеет встроенную поддержку открытых ключей на эллиптической кривой и обязательств Педерсена.
Обязательства Педерсена - это метод, позволяющий пользователю подтверждать какое-либо значение, которое не разглашается. То есть в случае разглашения этого значения благодаря этой схеме будет известно, что пользователь знал его на момент выдачи обязательства и что оно не изменилось.
Также, в отличие от zk-SNARKs, доказательства Bulletproofs имеют полный 128-битный уровень криптостойкости.
Уровень криптостойкости - это показатель криптостойкости криптографического алгоритма, связанный с вычислительной сложностью выполнения успешной атаки на криптосистему наиболее быстрым из известных алгоритмов
- в основе технологии Bulletproofs лежат общие принципы доказательства с нулевым разглашением (как и в zk-SNARKs);
- технология может использоваться для расширения многосторонних протоколов, таких как мультиподписи или условные платежи с нулевым знанием;
Bulletproofs был развернут в Monero. Важно понимать, что Bulletproofs доказательства сами по себе не способствуют обеспечению конфиденциальности. Они гарантируют, что информация, хранящаяся в конфиденциальной транзакции, не содержит ложных данных.
Monero для достижения анонимности полагается на три механизма: скрытые адреса, кольцевые подписи и кольцевые конфиденциальные транзакции. Bulletproofs влияют на кольцевые конфиденциальные транзакции или RingCT – способ, при помощи которого Monero скрывает сумму транзакции.
#Privacy
Bulletproofs (BP)
В этом посте затрагивал механизм Bulletproofs. Я попытался коротко и понятно. На счет коротко - не получилось. На счет понятно - на ваше усмотрение😉
⬇️⬇️⬇️
Bulletproofs (BP) - это короткие неинтерактивные доказательства с нулевым разглашением (Zero-knowledge proof), которые не требуют доверенной установки.
Т.е. позволяет одной из взаимодействующих сторон («The verifier» — проверяющей) убедиться в достоверности какого-либо утверждения, не имея при этом никакой другой информации от второй стороны («The prover» — доказывающей).
BP используется для того, чтобы убедить верификатора в том, что зашифрованный текст верен.
Например, нужно доказать, что зашифрованное число находится в заданном диапазоне, не раскрывая больше ничего об этом числе.
Каждая конфиденциальная транзакция содержит криптографическое доказательство того, что транзакция действительна. BP доказательства уменьшают размер криптографического доказательства с более чем 10 Кб до менее чем 1 кб.
Если бы все транзакции биткойнов были конфиденциальными и использовали bulletproofs доказательства, то общий размер UTXO составил бы только 17 ГБ, по сравнению с 160 ГБ с используемыми в настоящее время.
Bulletproofs позволяет:
- уменьшить доказательство платежеспособности
Доказательство платежеспособности свидетельствует о том, что валютный контроль обеспечивает достаточные резервы для расчетов по счетам каждого клиента. Механизм сохраняет конфиденциальность доказательства платежеспособности, в соответствии с которыми биржа не обязана раскрывать свои биткойн-адреса, совокупные активы или обязательства, а также любую информацию о своих клиентах. Также оно не позволяет биржам вступать в сговор для покрытия убытков друг друга. Финику и К привет😄
- внедрить конфиденциальные смарт-контракты и в качестве общей замены Sigma-протоколов.
Sigma-протоколы разработаны для обеспечения надежного обмена криптографическими ключами при обеспечении различных функций. Sigma служит криптографической основой для подписей IKE- стандартизированного протокола обмена ключами в Интернете.
- Возможность "коротких проверяемых смешиваний" (short verifiable shuffles)
Суть в том, что имея два списка фиксированных значений, доказать, что второй список - это перестановка первого. Этот метод можно использовать в голосовании и доказательстве платежеспособности. Такая схема позволяет реализовывать перетасовку и сортировку двух списков и затем проверять, что они равны.
По своей эффективности технология сопоставляется с zk-SNARKs или zk-STARKs, но имеет встроенную поддержку открытых ключей на эллиптической кривой и обязательств Педерсена.
Обязательства Педерсена - это метод, позволяющий пользователю подтверждать какое-либо значение, которое не разглашается. То есть в случае разглашения этого значения благодаря этой схеме будет известно, что пользователь знал его на момент выдачи обязательства и что оно не изменилось.
Также, в отличие от zk-SNARKs, доказательства Bulletproofs имеют полный 128-битный уровень криптостойкости.
Уровень криптостойкости - это показатель криптостойкости криптографического алгоритма, связанный с вычислительной сложностью выполнения успешной атаки на криптосистему наиболее быстрым из известных алгоритмов
- в основе технологии Bulletproofs лежат общие принципы доказательства с нулевым разглашением (как и в zk-SNARKs);
- технология может использоваться для расширения многосторонних протоколов, таких как мультиподписи или условные платежи с нулевым знанием;
Bulletproofs был развернут в Monero. Важно понимать, что Bulletproofs доказательства сами по себе не способствуют обеспечению конфиденциальности. Они гарантируют, что информация, хранящаяся в конфиденциальной транзакции, не содержит ложных данных.
Monero для достижения анонимности полагается на три механизма: скрытые адреса, кольцевые подписи и кольцевые конфиденциальные транзакции. Bulletproofs влияют на кольцевые конфиденциальные транзакции или RingCT – способ, при помощи которого Monero скрывает сумму транзакции.
#Privacy
Telegram
CryptoBotan
✅✅✅
Механизм обеспечения конфиденциальности для смарт-контрактов в сети эфира (ETH) - Zether.
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/874
Как и обещал описание протокола более подробно.
Zether - это полностью децентрализованный конфиденциальный платежный механизм…
Механизм обеспечения конфиденциальности для смарт-контрактов в сети эфира (ETH) - Zether.
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/874
Как и обещал описание протокола более подробно.
Zether - это полностью децентрализованный конфиденциальный платежный механизм…
✅✅✅
Протокол конфиденциальности Dandelion
Для стека биткоина
⬇️⬇️⬇️
Начну я с презентации своих старых постов на тему конфиденциальности:
MimbleWimble
CoinJoin, CoinShuffle и Stealth-Addresses
Bulletproofs
Теперь к нашим "Одуванчикам" (англ. Dandelion)...
Биткоин можно разделить на два уровня функционирования:
1) Прикладной уровень: управление транзакциями, блокчейн, майнинг, идентификация узлов в сети по PublicKey
2) Сетевой уровень: обработка связей между узлами через P2P-сеть, идентификация узлов по IP.
Суть в том, что сетевой уровень должен обладать:
а) низкой задержкой. Максимальное время, за которое сообщение достигнет всех узлов сети, должно быть небольшим и ограниченным.
б) анонимность. Невозможность связать сообщения от транзакциях с IP-адресом, который инициировал транзакцию.
Совершая транзакцию с узла, она передается всем связанным узлам, далее другим связанным, и по цепочке. Думаю, всем известный факт...Создается цепочка, которую можно отследить до начального узла. Каждый узел получающий данные о транзакции, становится доступным для запроса. Передача транзакции происходит с экспоненциальными задержками, что позволяет якобы усилить анонимность IP-адреса, но такое решение ее не обеспечивает. Ссылка, где объясняется способ деанонимизации транзакций и вычисление IP.
Летом 2017 года Shaileshh Bojja, Giulia Fant, Pramod Viswanath опубликовали BIP - сетевое решение для Биткойна, которое легко интегрируется в существующие блокчейн-сети. Протокол Dandelion - это решение для улучшения анонимизации на сетевом уровне.
Dandelion повышает конфиденциальность пользователей, отправляя транзакции через фазу анонимности, прежде чем передать их по сети. Dandelion повышает конфиденциальность за счет нарушения симметрии диффузии (форма передачи транзакции), и смешивания транзакций путем пересылки сообщений из разных источников по одному и тому же пути.
Версия "Одуванчик" предложенная в 2017 году имела ряд недостатков и потому в 2018 году вышла новая версия - Dandelion++. Протокол делает попытку деанонимизации - непрактичным.
Работает это все по аналогии с одуванчиком (см. рисунок ниже):
1) Stem Phase (фаза стебля)
Этот этап предназначен для избежания отслеживания транзакций к исходной. Каждый узел отправляет транзакцию одному рандомному (на основе алгоритма) узлу. Этот узел передает сообщение о транзакции другому рандомному узлу и т.д. Информация передается по переплетенным маршрутам. Они могут быть фрагментированы, но распространение ограничено локально. То есть транзакция остается анонимной для сети, кроме тех узлов, которые ее получают. В какой-то точке (каком-то из узлов) сообщение о транзакции транслируется в сеть. Эта какая-то точка определяется протоколом. Выбирается 4 одноранговых узла, позволяющих использовать 2 пути для передачи сообщения о транзакции.
2) Fluff Phase (фаза пуха)
Начало процесса диффузии (передачи транзакций в сеть).
"Распушивание" транзакции происходит либо:
- путем вероятностной игры, когда каждый узел, который получал транзакцию в фазе стебля с 90%-ой вероятностью, передает сообщение дальше
- путем истечения времени задержки, которое определяется индивидуально каждым узлом на фазе стебля.
Важно заметить, что при передаче сообщения о транзакции на стебле, каждый узел проверяет сеть на наличие этой транзакции. Если эта транзакция появилась в сети, узлы передают копию сообщения в сеть.
Протокол не требует сложных вычислений и может быть развернут без каких-либо изменений в базовом протоколе сети Биткойн.
#Privacy
Протокол конфиденциальности Dandelion
Для стека биткоина
⬇️⬇️⬇️
Начну я с презентации своих старых постов на тему конфиденциальности:
MimbleWimble
CoinJoin, CoinShuffle и Stealth-Addresses
Bulletproofs
Теперь к нашим "Одуванчикам" (англ. Dandelion)...
Биткоин можно разделить на два уровня функционирования:
1) Прикладной уровень: управление транзакциями, блокчейн, майнинг, идентификация узлов в сети по PublicKey
2) Сетевой уровень: обработка связей между узлами через P2P-сеть, идентификация узлов по IP.
Суть в том, что сетевой уровень должен обладать:
а) низкой задержкой. Максимальное время, за которое сообщение достигнет всех узлов сети, должно быть небольшим и ограниченным.
б) анонимность. Невозможность связать сообщения от транзакциях с IP-адресом, который инициировал транзакцию.
Совершая транзакцию с узла, она передается всем связанным узлам, далее другим связанным, и по цепочке. Думаю, всем известный факт...Создается цепочка, которую можно отследить до начального узла. Каждый узел получающий данные о транзакции, становится доступным для запроса. Передача транзакции происходит с экспоненциальными задержками, что позволяет якобы усилить анонимность IP-адреса, но такое решение ее не обеспечивает. Ссылка, где объясняется способ деанонимизации транзакций и вычисление IP.
Летом 2017 года Shaileshh Bojja, Giulia Fant, Pramod Viswanath опубликовали BIP - сетевое решение для Биткойна, которое легко интегрируется в существующие блокчейн-сети. Протокол Dandelion - это решение для улучшения анонимизации на сетевом уровне.
Dandelion повышает конфиденциальность пользователей, отправляя транзакции через фазу анонимности, прежде чем передать их по сети. Dandelion повышает конфиденциальность за счет нарушения симметрии диффузии (форма передачи транзакции), и смешивания транзакций путем пересылки сообщений из разных источников по одному и тому же пути.
Версия "Одуванчик" предложенная в 2017 году имела ряд недостатков и потому в 2018 году вышла новая версия - Dandelion++. Протокол делает попытку деанонимизации - непрактичным.
Работает это все по аналогии с одуванчиком (см. рисунок ниже):
1) Stem Phase (фаза стебля)
Этот этап предназначен для избежания отслеживания транзакций к исходной. Каждый узел отправляет транзакцию одному рандомному (на основе алгоритма) узлу. Этот узел передает сообщение о транзакции другому рандомному узлу и т.д. Информация передается по переплетенным маршрутам. Они могут быть фрагментированы, но распространение ограничено локально. То есть транзакция остается анонимной для сети, кроме тех узлов, которые ее получают. В какой-то точке (каком-то из узлов) сообщение о транзакции транслируется в сеть. Эта какая-то точка определяется протоколом. Выбирается 4 одноранговых узла, позволяющих использовать 2 пути для передачи сообщения о транзакции.
2) Fluff Phase (фаза пуха)
Начало процесса диффузии (передачи транзакций в сеть).
"Распушивание" транзакции происходит либо:
- путем вероятностной игры, когда каждый узел, который получал транзакцию в фазе стебля с 90%-ой вероятностью, передает сообщение дальше
- путем истечения времени задержки, которое определяется индивидуально каждым узлом на фазе стебля.
Важно заметить, что при передаче сообщения о транзакции на стебле, каждый узел проверяет сеть на наличие этой транзакции. Если эта транзакция появилась в сети, узлы передают копию сообщения в сеть.
Протокол не требует сложных вычислений и может быть развернут без каких-либо изменений в базовом протоколе сети Биткойн.
#Privacy
✅✅✅
Технология CoinSwap
Для стека биткоина
⬇️⬇️⬇️
Вы А и хотите отправить транзакцию продавцу Б, но не хотите, чтобы Б мог отследить ваши транзакции. Участник сети В предлагает свои услуги в виде посредника: он получает ваши монеты и отправляет Б другие - несвязанные монеты. Но в такой ситуации отсутствует доверие к каждой из сторон, ну если конечно вы не лучшие кореша, и то не всегда это доверие есть...
CoinSwap - это альтернативный метод обеспечения приватности для биткоина не связанный с хранением конфиденциальности, основанный на идее атомарных свопов. CoinSwap был предложен в 2013 году Грегори Максвеллом.
А может отправить BTC Б через В, где В не может их обмануть. А меняет BTC на то же количество BTC Б (минус комиссия), и делается это при помощи смарт-контрактов биткоина, чтобы исключить возможность мошенничества с любой из сторон. Проблема мошенничества решается при помощи "Hash time lock contracts" (HTLC).
Протокол требует четырех опубликованных транзакций, но транзакции выглядят как обычные 2 из 2 escrow transaction (два escrow платежа, два ecrow выпуска).
CoinSwaps разрушает связь транзакций между отправленными и полученными биткоинами. В блокчейне это выглядит как два набора полностью несвязанных транзакций:
Адрес А ---> эскроу адрес 1 ---> Адрес Б
Адрес Б ---> эскроу адрес 2 ---> Адрес А
Если сравнивать CoinJoin и CoinSwap, то можно определить некоторые существенные недостатки и преимущества.
Операции CoinJoin эффективны при объединении транзакций и могут экономить немного места. CoinSwap требует минимум четырех транзакций, хотя две Coinswap могут эффективно выполняться одновременно.
Набор анонимности CoinJoin равен количеству участников транзакции (или каскада транзакций). Набор анонимности CoinSwap - это все Coinswap происходящие одновременно, даже если пользователи не взаимодействуют друг с другом.
Транзакции CoinSwap выглядят как обычные транзакции 2-2 escrow. Если 2-2 escrow становятся общими, то операции CoinSwap могут быть менее идентифицируемыми, чем крупные операции CoinJoin с кучей выходов одинакового размера, и, следовательно, более устойчивыми к цензуре.
CoinSwaps требуют большого количества взаимодействий между вовлеченными сторонами, что может усложнить проектирование системы и избежать атак типа "отказ в обслуживании". Участники всегда должны иметь доступ к сети. Если интернет будет отключен, то наполовину завершенный CoinSwap может закончиться кражей средств одной из сторон.
Для достижения конфиденциальности, CoinJoin должна иметь много участников. Это усложняет разработку ПО.
CoinSwap эффективно нарушает связь между транзакциями в блокчейне, но это не решает всех проблем приватности и взаимозаменяемости. Посредник в сделке, все же знает о транзакции и может повторно восстановить связь между ними.
Именно эти проблемы и решает TumbleBit, о чем и напишу чуть позже.
#Privacy
Технология CoinSwap
Для стека биткоина
⬇️⬇️⬇️
Вы А и хотите отправить транзакцию продавцу Б, но не хотите, чтобы Б мог отследить ваши транзакции. Участник сети В предлагает свои услуги в виде посредника: он получает ваши монеты и отправляет Б другие - несвязанные монеты. Но в такой ситуации отсутствует доверие к каждой из сторон, ну если конечно вы не лучшие кореша, и то не всегда это доверие есть...
CoinSwap - это альтернативный метод обеспечения приватности для биткоина не связанный с хранением конфиденциальности, основанный на идее атомарных свопов. CoinSwap был предложен в 2013 году Грегори Максвеллом.
А может отправить BTC Б через В, где В не может их обмануть. А меняет BTC на то же количество BTC Б (минус комиссия), и делается это при помощи смарт-контрактов биткоина, чтобы исключить возможность мошенничества с любой из сторон. Проблема мошенничества решается при помощи "Hash time lock contracts" (HTLC).
Протокол требует четырех опубликованных транзакций, но транзакции выглядят как обычные 2 из 2 escrow transaction (два escrow платежа, два ecrow выпуска).
CoinSwaps разрушает связь транзакций между отправленными и полученными биткоинами. В блокчейне это выглядит как два набора полностью несвязанных транзакций:
Адрес А ---> эскроу адрес 1 ---> Адрес Б
Адрес Б ---> эскроу адрес 2 ---> Адрес А
Если сравнивать CoinJoin и CoinSwap, то можно определить некоторые существенные недостатки и преимущества.
Операции CoinJoin эффективны при объединении транзакций и могут экономить немного места. CoinSwap требует минимум четырех транзакций, хотя две Coinswap могут эффективно выполняться одновременно.
Набор анонимности CoinJoin равен количеству участников транзакции (или каскада транзакций). Набор анонимности CoinSwap - это все Coinswap происходящие одновременно, даже если пользователи не взаимодействуют друг с другом.
Транзакции CoinSwap выглядят как обычные транзакции 2-2 escrow. Если 2-2 escrow становятся общими, то операции CoinSwap могут быть менее идентифицируемыми, чем крупные операции CoinJoin с кучей выходов одинакового размера, и, следовательно, более устойчивыми к цензуре.
CoinSwaps требуют большого количества взаимодействий между вовлеченными сторонами, что может усложнить проектирование системы и избежать атак типа "отказ в обслуживании". Участники всегда должны иметь доступ к сети. Если интернет будет отключен, то наполовину завершенный CoinSwap может закончиться кражей средств одной из сторон.
Для достижения конфиденциальности, CoinJoin должна иметь много участников. Это усложняет разработку ПО.
CoinSwap эффективно нарушает связь между транзакциями в блокчейне, но это не решает всех проблем приватности и взаимозаменяемости. Посредник в сделке, все же знает о транзакции и может повторно восстановить связь между ними.
Именно эти проблемы и решает TumbleBit, о чем и напишу чуть позже.
#Privacy
✅✅✅
TumbleBit решение для конфиденциальных транзакций BTC
Для стека биткоина
⬇️⬇️⬇️
TumbleBit - это однонаправленный, несвязываемый платежный хаб. Протокол для анонимных платежей, полностью совместимый с протоколом Биткойн, так как реализован в виде слоя поверх сети.
В прошлом посте о CoinSwap я говорил, что TumbleBit решает вопрос с посредником, который знает о транзакции между А и Б, и потенциально может повторно восстановить связь между участниками.
Решение было предложено в 2016 году и представлено на конференции Scaling Bitcoin. После этого, другой разработчик, Николас Дориер презентовал свою имплементацию на языке C# - NTumbleBit. После чего она стала оффициальной имплементацией TumbleBit.
Платежи TumbleBit совершаются через посредника - Тамблер (Tumbler). Этот посредник не может деанонимизировать участников, украсть средства или выдать платежи сам себе.
TumbleBit позволяет совершать быстрые оффчейн платежи множеству получателей. Ничего не напоминает?? LN, Channel Factories. Платежи совершаются вне блокчейна, следовательно TumbleBit служит для масштабирования объема и скорости сети.
Участники открывают платежный канал, который депонирует BTC на депозитный адрес в блокчейн и совершают оффчейн платежи. Все как у LN, вот только с одной маленькой оговорочкой - эти платежи невозможно связать. Никто не может сказать кто перевел средства и кому их перевели.
Работает это так (по-крайней мере я так понял, да еще и долго думал писать или нет):
Для совершения неотслеживаемых транзакций используется TumbleBit, который решает криптографическую головоломку RSA.
А отправляет BTC в платежный канал с Тамблером (хабом). Средства принимаются только после того, как А представит решение головоломки. Это схема "Puzzle-Solver Protocol".
Б "заключает соглашение" с хабом. Тамблер заплатит Б после представления решения головоломки. Это схема "Puzzle-Promise Protocol".
TumbleBit знает, что решение действительно, но он не может точно определить, какую головоломку он решает, тем самым запутывая отношения между плательщиком и получателем.
TumbleBit также можно использовать как классический миксер, смешивая вместе передачу одного биткоина от Аn различных плательщиков к различным получателям Бn.
TumbleBit интегрирован с Tor, что уменьшает шанс быть раскрытым по IP, ведь пользователи подключаются к TumblerBit используя собственный адрес.
Сейчас идет поиск решений для повышения конфиденциальности сети Lightning при помощи TumblerBit.
Разработчики Stratis интегрировали TumbleBit в Breeze Wallet (пруф)
SPV HiddenWallet поддерживает решение TumbleBit (пруф). Кстати, статьи, приведенные ниже, написаны разработчиком этого кошелька и он же интегрировал Tor в TumbleBit. ☺️
В транслейте читаются легко.
Объяснение TumbleBit Часть 1
Объяснение TumbleBit Часть 2
Объяснение TumbleBit Часть 3
GitHub NTumbleBit
Documentation
#Privacy
TumbleBit решение для конфиденциальных транзакций BTC
Для стека биткоина
⬇️⬇️⬇️
TumbleBit - это однонаправленный, несвязываемый платежный хаб. Протокол для анонимных платежей, полностью совместимый с протоколом Биткойн, так как реализован в виде слоя поверх сети.
В прошлом посте о CoinSwap я говорил, что TumbleBit решает вопрос с посредником, который знает о транзакции между А и Б, и потенциально может повторно восстановить связь между участниками.
Решение было предложено в 2016 году и представлено на конференции Scaling Bitcoin. После этого, другой разработчик, Николас Дориер презентовал свою имплементацию на языке C# - NTumbleBit. После чего она стала оффициальной имплементацией TumbleBit.
Платежи TumbleBit совершаются через посредника - Тамблер (Tumbler). Этот посредник не может деанонимизировать участников, украсть средства или выдать платежи сам себе.
TumbleBit позволяет совершать быстрые оффчейн платежи множеству получателей. Ничего не напоминает?? LN, Channel Factories. Платежи совершаются вне блокчейна, следовательно TumbleBit служит для масштабирования объема и скорости сети.
Участники открывают платежный канал, который депонирует BTC на депозитный адрес в блокчейн и совершают оффчейн платежи. Все как у LN, вот только с одной маленькой оговорочкой - эти платежи невозможно связать. Никто не может сказать кто перевел средства и кому их перевели.
Работает это так (по-крайней мере я так понял, да еще и долго думал писать или нет):
Для совершения неотслеживаемых транзакций используется TumbleBit, который решает криптографическую головоломку RSA.
А отправляет BTC в платежный канал с Тамблером (хабом). Средства принимаются только после того, как А представит решение головоломки. Это схема "Puzzle-Solver Protocol".
Б "заключает соглашение" с хабом. Тамблер заплатит Б после представления решения головоломки. Это схема "Puzzle-Promise Protocol".
TumbleBit знает, что решение действительно, но он не может точно определить, какую головоломку он решает, тем самым запутывая отношения между плательщиком и получателем.
TumbleBit также можно использовать как классический миксер, смешивая вместе передачу одного биткоина от Аn различных плательщиков к различным получателям Бn.
TumbleBit интегрирован с Tor, что уменьшает шанс быть раскрытым по IP, ведь пользователи подключаются к TumblerBit используя собственный адрес.
Сейчас идет поиск решений для повышения конфиденциальности сети Lightning при помощи TumblerBit.
Разработчики Stratis интегрировали TumbleBit в Breeze Wallet (пруф)
SPV HiddenWallet поддерживает решение TumbleBit (пруф). Кстати, статьи, приведенные ниже, написаны разработчиком этого кошелька и он же интегрировал Tor в TumbleBit. ☺️
В транслейте читаются легко.
Объяснение TumbleBit Часть 1
Объяснение TumbleBit Часть 2
Объяснение TumbleBit Часть 3
GitHub NTumbleBit
Documentation
#Privacy
✅✅✅
ZeroLink - усовершенствованный CoinJoin
Для стека биткоина
⬇️⬇️⬇️
Посты на тему конфиденциальных платежей под тегом #Privacy
CoinJoin
MimbleWimble
CoinSwap
TumbleBit
Dandelion
Теперь поехалите...
Важным свойством денег является их взаимозаменяемость - идентичность каждой единицы каждой другой единице. Уже сейчас видно, как биржи блокируют средства, если они отмечаются как "грязные" или засвеченные в миксерах. А компании вроде Crystal или ChainAnalysis помогают им в этом. Подробнее о том, как правоохранительные органы используют блокчейн я писал в этом посте
Идеальная взаимозаменяемость требует, чтобы каждая биткойн-транзакция была неотличима друг от друга
Проблему взаимозаменяемости, которая присутствует сегодня, можно решить лишь при помощи улучшения конфиденциальности проведения платежей.
Протокол ZeroLink, от разработчиков HiddenWallet (тот что внедрил TumbleBit) и Samourai Wallet, предлагает технологию микширования Chaumian CoinJoin для обеспечения анонимности транзакций. ZeroLink разрывает связи между отдельными наборами монет.
Давайте по порядку:
CoinJoin был представлен еще в 2013 году и имеет огромное количество модификаций и вариаций использования: SharedCoin, Dark Wallet, DarkSend в Altcoin Dash, JoinMarket. Честно, не скажу, используют их сегодня или нет.😅
"Классический" CoinJoin работает так:
Несколько пользователей согласовывают и создают совместно подписанную транзакцию с множеством входов и выходов. Эта транзакция содержит средства из кошельков этих пользователей. Выходы общей транзакции перемешиваются и невозможно отследить кому и от кого шел каждый конкретный платеж.
Недостаток думаю понятен...Кто-то должен запустить такую транзакцию и пользователи проводящие CoinJoin-транзакцию знают друг о друге достаточно, чтобы восстановить цепочку транзакций: адрес отправителя, адрес получателя, количество монет, адрес сдачи. Похожая проблема существовала в CoinSwap (ссылочка выше).
Модификация Chaumian CoinJoin, которую предложил Maxwell - это система микширования, которая использует слепые подписи.
Слепые подписи основаны на схеме Дэвида Чаума (David Chaum). Подписывающая сторона не может точно знать содержимое подписываемого документа.
Каждый из пользователей отправляет вход для траты своих монет, адрес получения сдачи и криптографически замаскированную версию адреса, для совершения платежа.
Сервер проверяет и подписывает выход, а затем отправляет подпись обратно пользователю. Сервер не видит адрес отправки, так как используется слепая подпись. Пользователь анонимно переподключается к серверу и демаскирует (убирает ослепление) выходного, уже подписанного адреса. Сервер определяет, что все выходы были им подписаны и поступили от реальных участников, при чем он не знает какой вход, соответствует определенному выходу.
После этого пользователи снова анонимно переподключаются и предоставляют подписи. Сервер создает транзакцию CoinJoin и отправляет пользователям для подписи.
Ещё раз момент с подписями. Всего с подписями совершается два шага:
1) Сначала проставляется слепая подпись. Координатор узнает, кто какую подпись поставил.
2) Каждый участник анонимно подключается к серверу координатора и снимает ослепление с подписи.
Как итог, координатор не может определить кому принадлежит какая подпись
Суть в том, что не возможно украсть средства или деанонимизировать пользователей. Вся процедура занимает около минуты. Также такое взаимодействие может происходить при помощи анонимных сетей (TOR, I2P и т.д.)
На GitHub расписаны механизмы защиты от нарушения процессов создания транзакций недобросовестными участниками.
К решению ZeroLink вернулись в 2017 году, так как комиссии в сети Биткойн уже не нулевые, и нарушить процесс миксинга монет, при комиссиях около 1$ не выгодно экономически.
Samourai внедрил ZeroLink в Whirlpool.
#Privacy
ZeroLink - усовершенствованный CoinJoin
Для стека биткоина
⬇️⬇️⬇️
Посты на тему конфиденциальных платежей под тегом #Privacy
CoinJoin
MimbleWimble
CoinSwap
TumbleBit
Dandelion
Теперь поехалите...
Важным свойством денег является их взаимозаменяемость - идентичность каждой единицы каждой другой единице. Уже сейчас видно, как биржи блокируют средства, если они отмечаются как "грязные" или засвеченные в миксерах. А компании вроде Crystal или ChainAnalysis помогают им в этом. Подробнее о том, как правоохранительные органы используют блокчейн я писал в этом посте
Идеальная взаимозаменяемость требует, чтобы каждая биткойн-транзакция была неотличима друг от друга
Проблему взаимозаменяемости, которая присутствует сегодня, можно решить лишь при помощи улучшения конфиденциальности проведения платежей.
Протокол ZeroLink, от разработчиков HiddenWallet (тот что внедрил TumbleBit) и Samourai Wallet, предлагает технологию микширования Chaumian CoinJoin для обеспечения анонимности транзакций. ZeroLink разрывает связи между отдельными наборами монет.
Давайте по порядку:
CoinJoin был представлен еще в 2013 году и имеет огромное количество модификаций и вариаций использования: SharedCoin, Dark Wallet, DarkSend в Altcoin Dash, JoinMarket. Честно, не скажу, используют их сегодня или нет.😅
"Классический" CoinJoin работает так:
Несколько пользователей согласовывают и создают совместно подписанную транзакцию с множеством входов и выходов. Эта транзакция содержит средства из кошельков этих пользователей. Выходы общей транзакции перемешиваются и невозможно отследить кому и от кого шел каждый конкретный платеж.
Недостаток думаю понятен...Кто-то должен запустить такую транзакцию и пользователи проводящие CoinJoin-транзакцию знают друг о друге достаточно, чтобы восстановить цепочку транзакций: адрес отправителя, адрес получателя, количество монет, адрес сдачи. Похожая проблема существовала в CoinSwap (ссылочка выше).
Модификация Chaumian CoinJoin, которую предложил Maxwell - это система микширования, которая использует слепые подписи.
Слепые подписи основаны на схеме Дэвида Чаума (David Chaum). Подписывающая сторона не может точно знать содержимое подписываемого документа.
Каждый из пользователей отправляет вход для траты своих монет, адрес получения сдачи и криптографически замаскированную версию адреса, для совершения платежа.
Сервер проверяет и подписывает выход, а затем отправляет подпись обратно пользователю. Сервер не видит адрес отправки, так как используется слепая подпись. Пользователь анонимно переподключается к серверу и демаскирует (убирает ослепление) выходного, уже подписанного адреса. Сервер определяет, что все выходы были им подписаны и поступили от реальных участников, при чем он не знает какой вход, соответствует определенному выходу.
После этого пользователи снова анонимно переподключаются и предоставляют подписи. Сервер создает транзакцию CoinJoin и отправляет пользователям для подписи.
Ещё раз момент с подписями. Всего с подписями совершается два шага:
1) Сначала проставляется слепая подпись. Координатор узнает, кто какую подпись поставил.
2) Каждый участник анонимно подключается к серверу координатора и снимает ослепление с подписи.
Как итог, координатор не может определить кому принадлежит какая подпись
Суть в том, что не возможно украсть средства или деанонимизировать пользователей. Вся процедура занимает около минуты. Также такое взаимодействие может происходить при помощи анонимных сетей (TOR, I2P и т.д.)
На GitHub расписаны механизмы защиты от нарушения процессов создания транзакций недобросовестными участниками.
К решению ZeroLink вернулись в 2017 году, так как комиссии в сети Биткойн уже не нулевые, и нарушить процесс миксинга монет, при комиссиях около 1$ не выгодно экономически.
Samourai внедрил ZeroLink в Whirlpool.
#Privacy
✅✅✅
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
Для стека биткоина
Часть 1.
⬇️⬇️⬇️
SNICKER ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования") - это метод, позволяющий создать двухпартийный CoinJoin (CJ) без какой-либо синхронизации или взаимодействия между участниками.
Автором SNICKER является один из разработчиков JoinMarket Adam Gibson. SNICKER представлен в качестве проекта предложения по улучшению биткойна (BIP).
Чтобы совершить транзакцию-CJ пользователи должны подписать всю транзакцию, добавив все свои монеты и новые адреса получения. Они должны совершить транзакцию несколько раз и одновременно быть в сети. SNICKER же требует лишь сторону для передачи зашифрованных данных, а другую - для их получения.
Объясняя процесс SNICKER я использовал статью "SNICKER: How Alice And Bob Can Mix Bitcoin With No Interaction".
Повторное использование адресов:
Алиса имеет 1BTC, который она хочет миксануть и он представлен как UTXO в блокчейн. Он отправляет этот биткоин себе же, на свой же адрес, публично отмечая UTXO как потенциально доступный для микса.
Боб также имеет 1BTC и он не знает Алису, но знает, что где-то в сети есть такие пользователи, которые помечают свои UTXOs для микса. Боб сканирует блокчейн в поисках таких помеченных UTXOs, плюс ко всему находит повторно используемые адреса, которые недоступны для смешивания (о них чуть позже).
Так как Алиса, отправила биткоин на тот же адрес, ее PublicKey опубликован в блокчейне. Боб использует этот PublicKey Aлисы и объединяет его со своим PrivateKey для создания “shared secret”.
Shared secret - это часть данных, известных только вовлеченным сторонам в защищенном сообщении. Обычно это относится к ключу симметричной криптосистемы. Общий секрет может быть паролем, парольной фразой, большим числом или массивом случайно выбранных байтов.
Этот секрет является общим, потому что только Алиса и Боб могут генерировать его: Боб со своим PrivateKey и PublicKey Алисы, а Алиса со своим PrivateKey и PublicKey Боба (соответствующим монетам, которые они хотят смешать).
Итак: Боб имеет UTXO Алисы (потому что он помечен) и ее PublicKey + общий секрет.
Боб берет "общий секрет" и использует его для математической "настройки" PublicKey Алисы. Такая настройка создает новый PublicKey, но без PrivateKey...пока без него.
Тут интересный момент....Этот PrivateKey для нового PublicKey может быть обнаружен Алисой, при условии, что она изменит свой первоначальный PrivateKey при помощи общего секрета и полученный измененный PrivateKey соответствовал бы измененному PublicKey.
То есть Боб может генерировать новый PublicKey, а значит и новый адрес для Алисы, без ее ведома и который только она может потратить.
Итак: Боб имеет: UTXO Алисы, ее PublicKey, общий секрет и новый адрес для Алисы.
Боб создает транзакцию с двумя входами (UTXO Алисы и UTXO для своего биткоина). Он добавляет новый адрес Алисы и свой собственный адрес в качестве выходов и подписывает транзакцию.
Для создания транзакции-CoinJoin не хватает только подписи Алисы.
Боб шифрует транзакцию при помощи PublicKey Алисы, и только Алиса может расшифровать транзакцию. Боб публикует транзакцию на доске объявлений для пользователей SNICKER. Шифрование необходимо, так как, без него, потенциальный наблюдатель может определить какой вход принадлежит Бобу, а какой Алисе.
Транзакция CJ зашифрована и хоть Алиса и знает где искать, она не знает что искать. Алиса пытается расшифровать все предложенные объявления при помощи своего PrivateKey,
Найдя ту зашифрованную транзакцию, у Алисы есть все для завершения микса. Она использует свой PrivateKey и PublicKey Боба (в входных данных) для созданияобщего секрета, который она использует для создания нового PrivateKey. После проверки этого нового PrivateKey, который должен соответствовать ее новому, созданному Бобом, адресу, она подписывает и транслирует транзакцию в сеть.
Следующим постом разберу еще одну версию без повторного использования адреса.
#Privacy
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
Для стека биткоина
Часть 1.
⬇️⬇️⬇️
SNICKER ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования") - это метод, позволяющий создать двухпартийный CoinJoin (CJ) без какой-либо синхронизации или взаимодействия между участниками.
Автором SNICKER является один из разработчиков JoinMarket Adam Gibson. SNICKER представлен в качестве проекта предложения по улучшению биткойна (BIP).
Чтобы совершить транзакцию-CJ пользователи должны подписать всю транзакцию, добавив все свои монеты и новые адреса получения. Они должны совершить транзакцию несколько раз и одновременно быть в сети. SNICKER же требует лишь сторону для передачи зашифрованных данных, а другую - для их получения.
Объясняя процесс SNICKER я использовал статью "SNICKER: How Alice And Bob Can Mix Bitcoin With No Interaction".
Повторное использование адресов:
Алиса имеет 1BTC, который она хочет миксануть и он представлен как UTXO в блокчейн. Он отправляет этот биткоин себе же, на свой же адрес, публично отмечая UTXO как потенциально доступный для микса.
Боб также имеет 1BTC и он не знает Алису, но знает, что где-то в сети есть такие пользователи, которые помечают свои UTXOs для микса. Боб сканирует блокчейн в поисках таких помеченных UTXOs, плюс ко всему находит повторно используемые адреса, которые недоступны для смешивания (о них чуть позже).
Так как Алиса, отправила биткоин на тот же адрес, ее PublicKey опубликован в блокчейне. Боб использует этот PublicKey Aлисы и объединяет его со своим PrivateKey для создания “shared secret”.
Shared secret - это часть данных, известных только вовлеченным сторонам в защищенном сообщении. Обычно это относится к ключу симметричной криптосистемы. Общий секрет может быть паролем, парольной фразой, большим числом или массивом случайно выбранных байтов.
Этот секрет является общим, потому что только Алиса и Боб могут генерировать его: Боб со своим PrivateKey и PublicKey Алисы, а Алиса со своим PrivateKey и PublicKey Боба (соответствующим монетам, которые они хотят смешать).
Итак: Боб имеет UTXO Алисы (потому что он помечен) и ее PublicKey + общий секрет.
Боб берет "общий секрет" и использует его для математической "настройки" PublicKey Алисы. Такая настройка создает новый PublicKey, но без PrivateKey...пока без него.
Тут интересный момент....Этот PrivateKey для нового PublicKey может быть обнаружен Алисой, при условии, что она изменит свой первоначальный PrivateKey при помощи общего секрета и полученный измененный PrivateKey соответствовал бы измененному PublicKey.
То есть Боб может генерировать новый PublicKey, а значит и новый адрес для Алисы, без ее ведома и который только она может потратить.
Итак: Боб имеет: UTXO Алисы, ее PublicKey, общий секрет и новый адрес для Алисы.
Боб создает транзакцию с двумя входами (UTXO Алисы и UTXO для своего биткоина). Он добавляет новый адрес Алисы и свой собственный адрес в качестве выходов и подписывает транзакцию.
Для создания транзакции-CoinJoin не хватает только подписи Алисы.
Боб шифрует транзакцию при помощи PublicKey Алисы, и только Алиса может расшифровать транзакцию. Боб публикует транзакцию на доске объявлений для пользователей SNICKER. Шифрование необходимо, так как, без него, потенциальный наблюдатель может определить какой вход принадлежит Бобу, а какой Алисе.
Транзакция CJ зашифрована и хоть Алиса и знает где искать, она не знает что искать. Алиса пытается расшифровать все предложенные объявления при помощи своего PrivateKey,
Найдя ту зашифрованную транзакцию, у Алисы есть все для завершения микса. Она использует свой PrivateKey и PublicKey Боба (в входных данных) для созданияобщего секрета, который она использует для создания нового PrivateKey. После проверки этого нового PrivateKey, который должен соответствовать ее новому, созданному Бобом, адресу, она подписывает и транслирует транзакцию в сеть.
Следующим постом разберу еще одну версию без повторного использования адреса.
#Privacy
✅✅✅
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
Для стека биткоина
Часть.2
Повторно использованные подписанные входные данные
⬇️⬇️⬇️
Вторую версию SNICKER также описал Adam Gibson. В ней удалось избежать необходимости повторного использования адреса - за счет некоторого усложнения.
В этом варианте, Боб берет PublicKey из входных данных транзакции которая создала UTXO Алисы, а не из повторно используемого адреса, как в 1 варианте.
Боб полагает, что один из входов этой транзакции был создан самой Алисой, и у нее есть PrivateKey для него. Это верно, так как UTXO Алисы обозначен как готовый к миксингу и что владелец, т.е.Алиса, владеет PrivateKey.
В BIP не указывается как будет выполнена первоначальная маркировка. Но есть предположение что некоторые кошельки (например JoinMarket) смогут видеть такую информацию.
Альтернативным вариантом, Алиса могла бы разместить сообщение на доске объявлений, а именно засветить UTXO.
Как только SNICKER начнет использоваться, поиск запросов на миксинг станет проще. Сами SNIKER -транзакции просты для распознавания. Поэтому после начальной фазы загрузки несмешанные монеты будут смешиваться с ранее смешиваемыми монетами, и в свою очередь могут быть использованы для следующего смешивания...
Как упоминалось в 1 варианте, Существует проблема выбора "тех самых" UTXO, которые готовы к миксингу и уменьшение количества ложных совпадений.
Ложные совпадения, это помеченные UTXO, уже пройденные этап миксинга или проходящие в данный момент. Потенциальные совпадения могут быть отфильтрованы по суммам, возрасту UTXO или типа используемых кошельков.
Один из вариантов: Боб использует один и тот же UTXO для всех объявлений. То есть первый кто успеет проведет миксинг. Другие же, желающие провести миксинг, остаются неудел, но проблем не возникнет.Предложение Боба будет просто висеть на доске пока не удалят или навсегда.
Проблема номер 2: Так как доска объявлений будет содержать зашифрованные "запросы", то невозможно будет отфильтровать "поддельные" предложения. Одним из решений проблемы являются затраты на публикацию предложения.
Очень интересное преимущество предоставляет SNICKER. Боб, который заинтересован в миксе своих монет, может добавлять средства к выходу принимающей стороны, для стимулирования желания провести миксинг.
Так же, не отрицается возможность и использования троих сторон в миксе, но это будет довольно сложна схема.
#Privacy
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
Для стека биткоина
Часть.2
Повторно использованные подписанные входные данные
⬇️⬇️⬇️
Вторую версию SNICKER также описал Adam Gibson. В ней удалось избежать необходимости повторного использования адреса - за счет некоторого усложнения.
В этом варианте, Боб берет PublicKey из входных данных транзакции которая создала UTXO Алисы, а не из повторно используемого адреса, как в 1 варианте.
Боб полагает, что один из входов этой транзакции был создан самой Алисой, и у нее есть PrivateKey для него. Это верно, так как UTXO Алисы обозначен как готовый к миксингу и что владелец, т.е.Алиса, владеет PrivateKey.
В BIP не указывается как будет выполнена первоначальная маркировка. Но есть предположение что некоторые кошельки (например JoinMarket) смогут видеть такую информацию.
Альтернативным вариантом, Алиса могла бы разместить сообщение на доске объявлений, а именно засветить UTXO.
Как только SNICKER начнет использоваться, поиск запросов на миксинг станет проще. Сами SNIKER -транзакции просты для распознавания. Поэтому после начальной фазы загрузки несмешанные монеты будут смешиваться с ранее смешиваемыми монетами, и в свою очередь могут быть использованы для следующего смешивания...
Как упоминалось в 1 варианте, Существует проблема выбора "тех самых" UTXO, которые готовы к миксингу и уменьшение количества ложных совпадений.
Ложные совпадения, это помеченные UTXO, уже пройденные этап миксинга или проходящие в данный момент. Потенциальные совпадения могут быть отфильтрованы по суммам, возрасту UTXO или типа используемых кошельков.
Один из вариантов: Боб использует один и тот же UTXO для всех объявлений. То есть первый кто успеет проведет миксинг. Другие же, желающие провести миксинг, остаются неудел, но проблем не возникнет.Предложение Боба будет просто висеть на доске пока не удалят или навсегда.
Проблема номер 2: Так как доска объявлений будет содержать зашифрованные "запросы", то невозможно будет отфильтровать "поддельные" предложения. Одним из решений проблемы являются затраты на публикацию предложения.
Очень интересное преимущество предоставляет SNICKER. Боб, который заинтересован в миксе своих монет, может добавлять средства к выходу принимающей стороны, для стимулирования желания провести миксинг.
Так же, не отрицается возможность и использования троих сторон в миксе, но это будет довольно сложна схема.
#Privacy
✅✅✅
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования")
Для стека биткоина
⬇️⬇️⬇️
Часть 1. Повторное использование адресов:
Часть 2. Повторно использованные подписанные входные данные
BIP SNICKER
Статья используемая для описания работы протокола
#Privacy
SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused ("Простые неинтерактивные Coinjoins с ключами для повторного использования шифрования")
Для стека биткоина
⬇️⬇️⬇️
Часть 1. Повторное использование адресов:
Часть 2. Повторно использованные подписанные входные данные
BIP SNICKER
Статья используемая для описания работы протокола
#Privacy
✅✅✅
Confidential transactions (CT) - Конфиденциальные транзакции
Для стека биткоина
⬇️⬇️⬇️
Продолжая направление #Privacy сегодня о конфиденциальных транзакциях.
Анализ блокчейна, мониторинг сети, KYC, AML, нарушение принципа взаимозаменяемости - все это уже работает для того, чтобы определить, посчитать, добавить в базу и взять под контроль тебя и твои биткоины. Это бесконечная гонка, где с одной стороны регуляторы, в виде корпораций, государств и твоих кредиторов,а с другой - борцы за анонимность, приватность и свободу.
Ну а сегодня, про еще один ход черных...или белых...в этой шахматной партии. Если честно, тут тоже сложно определить, кто на чей стороне, да и не суть...В этой игре по ходу, каждый сам за себя😏
Все транзакции в сети Биткойн записаны в блокчейн. Это является как плюсом так и минусом. С одной стороны, доверие без доверия, с другой - возможность тривиального отслеживания количества BTC, с адресов на адреса.
Решить проблему можно, скрыв количество BTC в совершаемой транзакции.
Еще в 2013 году, Адам Бэк, предложил эту концепцию под названием “bitcoins with homomorphic value”. Позже ее подхватили нынешние "двигатели" развития: Gregory Maxwell, Dr. Pieter Wuille, Andrew Poelstra. В итоге на свет появились Confidential Transactions.
Confidential Transactions - это криптографический метод сокрытия суммы отправляемых и получаемых средств.
CT полностью скрывает суммы на входах и выходах транзакции, давая возможность проверить, что сумма всех выходов не превышает сумму всех входов.
Чуть подробнее:
В основе решения лежат Борромеевские кольцевые подписи и схемы обязательств Педерсена.
Боромеевские кольцевые подписи - новый тип кольцевой подписи, основанный на задаче дискретного логарифма, который использовал новую структуру обязательств для получения значительной экономии размера и времени проверки кольцевых подписей.
Если кому интересно, вот ссылочка на документацию.
Cхемы обязательств Педерсена (Petersen Commitment) - это криптографическая схема, позволяющая зафиксировать сообщение каким-либо значением, сохраняя сообщение в секрете, с возможностью последующего раскрытия зафиксированного значения. Схемы обязательств разработаны таким образом, что ни одна из сторон не может изменить сообщение после того, как они его зафиксировали. Используются для того, чтобы одна сторона могла доказать, знание секрета, не раскрывая его.
Схемы обязательств используются в интерактивном криптографическом протоколе "Zero-knowledge proof", а тот в свою очередь в Bulletproofs для BTC, в ZCash и его форках.
В Confidential Transactions используется Petersen Commitment для доказательства того, что сумма выходов не превышает сумму входов. То есть благодаря ему и скрывается сумма перевода.
В качестве суммы в commitments можно использовать отрицательное число, что приведет к неконтролируемой эмиссией монет. Range Proofs используется как раз для доказательства использования неотрицательных сумм. Проще говоря, Range Proofs - это доказательство, где каждый commitment подписан кольцевой подписью Борромео и гарантирует, что сумма находится в заданном интервале.
Проблема здесь в Range Proofs. На их создание уходит большое количество ресурсов и они имеют достаточно большой объем, что приведет к высоким комиссиям в сети.
Еще одной недогляделкой является тот факт, что суммы скрываются для конкретной транзакции. Если следующая транзакция не является конфиденциальной, предыдущие действия были бессмысленны.
CT скрывают суммы транзакций, но не адреса отправителя и получателя. Тут то и можно использовать CoinJoin или CoinSwap, с которыми CT совместим.
Так же при проведении Soft Fork, встает вопрос, о синхронизации старых и новых узлов.
В криптовалюте Monero используется версия CT - Ring Confidential Transactions, где вместо подписей Борромео (об этом ниже) используется Bulletproofs. BitShares использует CT совместно с Stealth Addresses. CT имплементированы в Liquid от Blockstream.
Confidential Transactions.txt by Greg Maxwell
О RingCT в Monero
#Privacy
Confidential transactions (CT) - Конфиденциальные транзакции
Для стека биткоина
⬇️⬇️⬇️
Продолжая направление #Privacy сегодня о конфиденциальных транзакциях.
Анализ блокчейна, мониторинг сети, KYC, AML, нарушение принципа взаимозаменяемости - все это уже работает для того, чтобы определить, посчитать, добавить в базу и взять под контроль тебя и твои биткоины. Это бесконечная гонка, где с одной стороны регуляторы, в виде корпораций, государств и твоих кредиторов,а с другой - борцы за анонимность, приватность и свободу.
Ну а сегодня, про еще один ход черных...или белых...в этой шахматной партии. Если честно, тут тоже сложно определить, кто на чей стороне, да и не суть...В этой игре по ходу, каждый сам за себя😏
Все транзакции в сети Биткойн записаны в блокчейн. Это является как плюсом так и минусом. С одной стороны, доверие без доверия, с другой - возможность тривиального отслеживания количества BTC, с адресов на адреса.
Решить проблему можно, скрыв количество BTC в совершаемой транзакции.
Еще в 2013 году, Адам Бэк, предложил эту концепцию под названием “bitcoins with homomorphic value”. Позже ее подхватили нынешние "двигатели" развития: Gregory Maxwell, Dr. Pieter Wuille, Andrew Poelstra. В итоге на свет появились Confidential Transactions.
Confidential Transactions - это криптографический метод сокрытия суммы отправляемых и получаемых средств.
CT полностью скрывает суммы на входах и выходах транзакции, давая возможность проверить, что сумма всех выходов не превышает сумму всех входов.
Чуть подробнее:
В основе решения лежат Борромеевские кольцевые подписи и схемы обязательств Педерсена.
Боромеевские кольцевые подписи - новый тип кольцевой подписи, основанный на задаче дискретного логарифма, который использовал новую структуру обязательств для получения значительной экономии размера и времени проверки кольцевых подписей.
Если кому интересно, вот ссылочка на документацию.
Cхемы обязательств Педерсена (Petersen Commitment) - это криптографическая схема, позволяющая зафиксировать сообщение каким-либо значением, сохраняя сообщение в секрете, с возможностью последующего раскрытия зафиксированного значения. Схемы обязательств разработаны таким образом, что ни одна из сторон не может изменить сообщение после того, как они его зафиксировали. Используются для того, чтобы одна сторона могла доказать, знание секрета, не раскрывая его.
Схемы обязательств используются в интерактивном криптографическом протоколе "Zero-knowledge proof", а тот в свою очередь в Bulletproofs для BTC, в ZCash и его форках.
В Confidential Transactions используется Petersen Commitment для доказательства того, что сумма выходов не превышает сумму входов. То есть благодаря ему и скрывается сумма перевода.
В качестве суммы в commitments можно использовать отрицательное число, что приведет к неконтролируемой эмиссией монет. Range Proofs используется как раз для доказательства использования неотрицательных сумм. Проще говоря, Range Proofs - это доказательство, где каждый commitment подписан кольцевой подписью Борромео и гарантирует, что сумма находится в заданном интервале.
Проблема здесь в Range Proofs. На их создание уходит большое количество ресурсов и они имеют достаточно большой объем, что приведет к высоким комиссиям в сети.
Еще одной недогляделкой является тот факт, что суммы скрываются для конкретной транзакции. Если следующая транзакция не является конфиденциальной, предыдущие действия были бессмысленны.
CT скрывают суммы транзакций, но не адреса отправителя и получателя. Тут то и можно использовать CoinJoin или CoinSwap, с которыми CT совместим.
Так же при проведении Soft Fork, встает вопрос, о синхронизации старых и новых узлов.
В криптовалюте Monero используется версия CT - Ring Confidential Transactions, где вместо подписей Борромео (об этом ниже) используется Bulletproofs. BitShares использует CT совместно с Stealth Addresses. CT имплементированы в Liquid от Blockstream.
Confidential Transactions.txt by Greg Maxwell
О RingCT в Monero
#Privacy
✅✅✅
P2EP - Pay to Endpoint (Оплата до конечной точки)
Для стека биткоина
⬇️⬇️⬇️
Решение P2EP было предложено на так называемом "brainstorming event on Bitcoin privacy". Участники этого ивента предлагали решения для улучшения базовой конфиденциальности транзакций в Биткойн.
Есть еще несколько реализаций P2EP:
1) PayJoin для JoinMarket от Adam Gibson
2) Bustapay базовая версия P2EP от Havar
Основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев.
Цель создания P2EP: обеспечить способ гарантировать, что операции с входными данными, принадлежащими более чем одной стороне, являются достаточно распространенным явлением.
P2EP - это особый тип CoinJoin-транзакций.
Ограничения использования CoinJoin:
- если все участники CoinJoin не используют равные суммы, то можно определить какие входы, оплачивают выходы
- наблюдатель может определить, что это CoinJoin-транзакция, а следовательно, нарушается принцип взаимозаменяемости.
P2EP устраняет ограничения классического CoinJoin и может использоваться для регулярных платежей.
Суть P2EP такова, что и отправитель, и получатель вносят входные данные в транзакцию посредством взаимодействий, координируемых конечной точкой, которую представляет получатель, используя совместимый URI BIP 21.
BIP 21 предлагает схему URI для осуществления биткойн-платежей.
Б (получатель) генерирует URI BIP 21 с параметром определяющим конечную точку P2EP.
А (отправитель) инициирует взаимодействие с Б, подтверждая, что предоставленная конечная точка доступна. Если конечная точка Б доступна, А предоставляет Б подписанную транзакцию в качестве доказательства владения UTXO.
Затем Б отправляет несколько транзакций А, которые он должен подписать. Из этих транзакций только одна включает в себя UTXO, который фактически принадлежит Б, остальные могут быть выбраны из пула расходуемых UTXOs. После эти транзакции могут быть отправлены либо последовательно, либо параллельно отправителю.
Каждый подход отправки транзакций имеет свои плюсы и минусы. Но стоит заметить, что есть и третий подход для обмена UTXO. Это Bulletproofs который я довольно много в последнее время упоминаю...
Когда Б получает подписанную транзакцию, которая соответствует их UTXO, они могут подписать и транслировать транзакцию, которая теперь будет содержать входные данные как от А, так и от Б.
В случае сбоя P2EP по любым причинам транзакция передается как обычная.
Пример:
Если Алиса хочет отправить Бобу 1.2 BTC, то она может отправить их с двух входов: 1 и 0.5 BTC. Лишние 0.3 BTC отправялются обратно в виде сдачи.
При помощи P2EP Боб добавляет один свой вход в транзакцию, например 0.9 BTC. Теперь транзакция имеет 3 входа 1+0.9+0.5 = 2.4 BTC, и два адреса: 2.1 и 0.3 BTC. В итоге Алиса заплатила 1.2 BTC, несмотря на некоторое усложнение.
Здесь то и достигнута цель, которую я описал в самом начале. Не все входы принадлежат Алисе, следовательно тот факт, что это CoinJoin транзакция, не очевиден. Нет совпадающих сумм при отправке и получении, а значит и связать адреса вместе не представляется возможным. Такие транзакции можно интерпретировать как оплачивающие что-то с остатками сдачи.
Такие транзакции нарушают эвристику "общего владения входными данными" и улучшают конфиденциальность, тем самым не отличаясь от обычных транзакций.
Нет ничего совершенного, поэтому некоторые недостатки:
1) Обе стороны сделки должны быть онлайн.
2) Получатель должен иметь "hot wallet" для подписи транзакций.
3) Более высокие комиссионные сборы из-за увеличения объема транзакции.
4) Получатель должен иметь доступ к полному узлу
На сегодняшний день, это одно из самых обсуждаемых разработок в направлении #Privacy
Статья Blockstream
Статья на Medium by Nopara73
P2EP - Pay to Endpoint (Оплата до конечной точки)
Для стека биткоина
⬇️⬇️⬇️
Решение P2EP было предложено на так называемом "brainstorming event on Bitcoin privacy". Участники этого ивента предлагали решения для улучшения базовой конфиденциальности транзакций в Биткойн.
Есть еще несколько реализаций P2EP:
1) PayJoin для JoinMarket от Adam Gibson
2) Bustapay базовая версия P2EP от Havar
Основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев.
Цель создания P2EP: обеспечить способ гарантировать, что операции с входными данными, принадлежащими более чем одной стороне, являются достаточно распространенным явлением.
P2EP - это особый тип CoinJoin-транзакций.
Ограничения использования CoinJoin:
- если все участники CoinJoin не используют равные суммы, то можно определить какие входы, оплачивают выходы
- наблюдатель может определить, что это CoinJoin-транзакция, а следовательно, нарушается принцип взаимозаменяемости.
P2EP устраняет ограничения классического CoinJoin и может использоваться для регулярных платежей.
Суть P2EP такова, что и отправитель, и получатель вносят входные данные в транзакцию посредством взаимодействий, координируемых конечной точкой, которую представляет получатель, используя совместимый URI BIP 21.
BIP 21 предлагает схему URI для осуществления биткойн-платежей.
Б (получатель) генерирует URI BIP 21 с параметром определяющим конечную точку P2EP.
А (отправитель) инициирует взаимодействие с Б, подтверждая, что предоставленная конечная точка доступна. Если конечная точка Б доступна, А предоставляет Б подписанную транзакцию в качестве доказательства владения UTXO.
Затем Б отправляет несколько транзакций А, которые он должен подписать. Из этих транзакций только одна включает в себя UTXO, который фактически принадлежит Б, остальные могут быть выбраны из пула расходуемых UTXOs. После эти транзакции могут быть отправлены либо последовательно, либо параллельно отправителю.
Каждый подход отправки транзакций имеет свои плюсы и минусы. Но стоит заметить, что есть и третий подход для обмена UTXO. Это Bulletproofs который я довольно много в последнее время упоминаю...
Когда Б получает подписанную транзакцию, которая соответствует их UTXO, они могут подписать и транслировать транзакцию, которая теперь будет содержать входные данные как от А, так и от Б.
В случае сбоя P2EP по любым причинам транзакция передается как обычная.
Пример:
Если Алиса хочет отправить Бобу 1.2 BTC, то она может отправить их с двух входов: 1 и 0.5 BTC. Лишние 0.3 BTC отправялются обратно в виде сдачи.
При помощи P2EP Боб добавляет один свой вход в транзакцию, например 0.9 BTC. Теперь транзакция имеет 3 входа 1+0.9+0.5 = 2.4 BTC, и два адреса: 2.1 и 0.3 BTC. В итоге Алиса заплатила 1.2 BTC, несмотря на некоторое усложнение.
Здесь то и достигнута цель, которую я описал в самом начале. Не все входы принадлежат Алисе, следовательно тот факт, что это CoinJoin транзакция, не очевиден. Нет совпадающих сумм при отправке и получении, а значит и связать адреса вместе не представляется возможным. Такие транзакции можно интерпретировать как оплачивающие что-то с остатками сдачи.
Такие транзакции нарушают эвристику "общего владения входными данными" и улучшают конфиденциальность, тем самым не отличаясь от обычных транзакций.
Нет ничего совершенного, поэтому некоторые недостатки:
1) Обе стороны сделки должны быть онлайн.
2) Получатель должен иметь "hot wallet" для подписи транзакций.
3) Более высокие комиссионные сборы из-за увеличения объема транзакции.
4) Получатель должен иметь доступ к полному узлу
На сегодняшний день, это одно из самых обсуждаемых разработок в направлении #Privacy
Статья Blockstream
Статья на Medium by Nopara73
Немного про повторное использование ключей
⬇️⬇️⬇️
Совершая транзакцию и отправитель и получатель раскрывают друг другу PublicKeys и PublicAddresses, которые используются в транзакции.
Если один и тот же PublicKey использовать повторно, например биткойн-адреса в качестве статических платежных адресов, то можно отследить пути расходования и получения, а также количество средств. А потом, как пример, спросить за эти полученные средства.
Но возможна и ситуация, когда использование каждого PublicKeys происходит лишь дважды - для получения платежа и для отправки платежа. Тогда пользователь вполне конфиденциален. Хоть и не настолько, насколько хотелось бы, особенно если у тебя действительно крупная сумма.
Для больше конфиденциальности, можно использовать методы микширования или сокрытия сумм и адресов, вроде СoinJoin и его имплементаций, о которых я уже писал ранее под тегом #Privacy.
Избегая потворное использование ключей, можно обеспечить защиту от атак, вроде "восстановление PrivateKey из PublicKey" или "сравнение сигнатур".
Во избежание атак по восстановлению PrivateKey из PublicKey используются уникальные адреса P2PKH и P2SH (вот тут писал о них). Они сохраняют PublicKeys ECDSA хэшированными, пока не произойдет первая трата, отправленных монет на этот адрес. Если способ восстановления PrivateKey не осуществим менее чем за час, то она бессмысленна.
Уникальные PrivateKeys защищают от атаки "сравнение сигнатур", генерируя одну подпись на каждый PrivateKey. Потому, атакующий не сможет получить последующую подпись для использования сравнения.
Стоит избегать повторного использования PublicKeys, а также повторного использования адресов. Если же вам нужно использовать фиксированный URI, то P2EP, который имеет все шансы скорое принятие, может вам с этим помочь, сохранив вашу приватность.
#Privacy
⬇️⬇️⬇️
Совершая транзакцию и отправитель и получатель раскрывают друг другу PublicKeys и PublicAddresses, которые используются в транзакции.
Если один и тот же PublicKey использовать повторно, например биткойн-адреса в качестве статических платежных адресов, то можно отследить пути расходования и получения, а также количество средств. А потом, как пример, спросить за эти полученные средства.
Но возможна и ситуация, когда использование каждого PublicKeys происходит лишь дважды - для получения платежа и для отправки платежа. Тогда пользователь вполне конфиденциален. Хоть и не настолько, насколько хотелось бы, особенно если у тебя действительно крупная сумма.
Для больше конфиденциальности, можно использовать методы микширования или сокрытия сумм и адресов, вроде СoinJoin и его имплементаций, о которых я уже писал ранее под тегом #Privacy.
Избегая потворное использование ключей, можно обеспечить защиту от атак, вроде "восстановление PrivateKey из PublicKey" или "сравнение сигнатур".
Во избежание атак по восстановлению PrivateKey из PublicKey используются уникальные адреса P2PKH и P2SH (вот тут писал о них). Они сохраняют PublicKeys ECDSA хэшированными, пока не произойдет первая трата, отправленных монет на этот адрес. Если способ восстановления PrivateKey не осуществим менее чем за час, то она бессмысленна.
Уникальные PrivateKeys защищают от атаки "сравнение сигнатур", генерируя одну подпись на каждый PrivateKey. Потому, атакующий не сможет получить последующую подпись для использования сравнения.
Стоит избегать повторного использования PublicKeys, а также повторного использования адресов. Если же вам нужно использовать фиксированный URI, то P2EP, который имеет все шансы скорое принятие, может вам с этим помочь, сохранив вашу приватность.
#Privacy
✅✅✅
Cross-Input Aggregation - Агрегация перекрестного ввода
Для стека биткоина
⬇️⬇️⬇️
Так, так...нам снова придется вернуться к подписям Шнорра и затронуть MuSig.
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ.
Multisig-транзакции не поддерживаются ECDSA и потому реализуются при помощи смарт-контракта P2SH.
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна.
Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы.
Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot, который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation).
Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1.
Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin. Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP: "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
#PerfomanceAndUsability
Cross-Input Aggregation - Агрегация перекрестного ввода
Для стека биткоина
⬇️⬇️⬇️
Так, так...нам снова придется вернуться к подписям Шнорра и затронуть MuSig.
Схема Шнорра — это протокол идентификации и метод агрегирования (суммирование) подписей, необходимых для транзакции BTC. Подписи Шнорра позволяют создавать подпись действительную для суммы PublicKeys. Несколько подписывающих лиц в транзакции-multisig, объединяют свои PublicKeys в агрегированный ключ.
Multisig-транзакции не поддерживаются ECDSA и потому реализуются при помощи смарт-контракта P2SH.
1) P2SH требуют знания PublicKeys все подписавшихся участников multisig, что не особо радует. Агрегирование этих ключей позволит обеспечить более эффективную проверку, т.к. придется проверить лишь один ключ, а не n-ключей.
2) Транзакции P2SH требуют адреса начинающихся с числа 3 (см. BIP 13). А это удар по конфиденциальности. Агрегирование ключей позволяет multisig выглядеть как обычная транзакция.
Прежде чем перейти к теме поста, еще затронем MuSig. Это новая схема мультиподписи на основе Шнорр. Агрегация ключей в MuSig позволяет создавать частные смарт-контракты за пределами блокчейна.
Итак, агрегация ключей это крутая плюшка для multisig-транзакций, которые тратят один вход. Но биткойн-транзакции чаще всего имеют больше одного входа?В будущем, подписи Шнорра могут быть использованы для создания интерактивной схемы агрегированной подписи (interactive aggregate signature - IAS).
IAS - расширяют схемы multisig, позволяя каждому подписавшему подписать свое сообщение и вместо подписей для каждого отдельного входа, можно использовать одну подпись, которая проверит все входы.
Теперь одна подпись может использоваться для траты всех входных данных транзакции. Каждый вход также будет иметь свой собственный PublicKey, но его можно будет использовать с помощью IAS Schnorr. Эту новую подпись можно очень легко проверить с помощью OPCHECKDLS, который является новым опкодом и будет введен в схему подписи Schnorr.
Taproot, который предназначается для увеличения гибкости смарт-контрактов, призван облегчить переход от агрегации ключей к агрегации перекрестного ввода (Cross-Input Aggregation).
Для каждой транзакции требуется более одной подписи - по одной на каждый вход. Агрегация подписей с перекрестным вводом обеспечивает экономию, за счет сокращения количества подписей на транзакцию до 1.
Комбинация данных ввода повышает конфиденциальность и освобождает пространство, которое ранее использовалось для размещения всех подписей на множестве разных входов.
Cross-input aggregation может улучшить транзакции CoinJoin. Решение вводит дополнительный механизм запутывания на уровне протокола. С его помощью можно построить основанные на Шнорр CJ-транзакции с n-подписями, которые выглядят как обычные транзакции с одной подписью. Проблемы с конфиденциальностью были разобраны мной в постах под тегом #Privacy.
Как уже писалось в посте про P2EP: "основной принцип анализа блокчейна включает в себя PublicKey которые используются в качестве входных данных для транзакций, контролируемые одним и тем же пользователем. Чтобы утверждение "об общем владении входными данными" было признано недействительным, необходимо, чтобы существовало достаточное количество транзакций которые разделяют входные данные от разных владельцев".
P2EP обратно совместим, и при использовании в сочетании со Schnorr он может обеспечить достаточную конфиденциальность в базовом слое биткойна.
Cross-input aggregation имеет ряд проблем и не может быть внедрен по ряду причин. В любом случае, без внедрения подписей Шнорра, сделать это будет невозможно.
#PerfomanceAndUsability
✅✅✅
Value Shuffle - протокол микширования на базе CoinJoin
Для стека биткоина
Продолжая говорить о конфиденциальности, повторю, одно из основных свойств Биткойна, это его взаимозаменяемость. Актуально, исходя из новостей про ETHProtect в Etherscan, позволяющий отслеживать скомпрометированные монеты, а также о сервисах анализа блокчейна Биткойн. Итог: две одинаковые монеты - не равны.
Проблема тут в улучшениях для повышения конфиденциальности, т.к. такие решения либо направляют свой фокус на решение одного аспекта конфиденциальности, либо требуют серьезных изменений функционала в коде Биткойна.
Value Shuffle - это протокол микширования монет на базе CoinJoin, реализуемый при помощи Confidential Transaction и Stealth Addresses.
В своей статье ниже, и о протоколе Value Shuffle, и небольшой итог моих исследований под тегом #Privacy. На этом я не остановлюсь и мы дальше продолжим знакомиться с протоколами конфиденциальности.
⬇️⬇️⬇️
https://teletype.in/@russiano55/ValueShuffleforBitcoin
#Privacy
Value Shuffle - протокол микширования на базе CoinJoin
Для стека биткоина
Продолжая говорить о конфиденциальности, повторю, одно из основных свойств Биткойна, это его взаимозаменяемость. Актуально, исходя из новостей про ETHProtect в Etherscan, позволяющий отслеживать скомпрометированные монеты, а также о сервисах анализа блокчейна Биткойн. Итог: две одинаковые монеты - не равны.
Проблема тут в улучшениях для повышения конфиденциальности, т.к. такие решения либо направляют свой фокус на решение одного аспекта конфиденциальности, либо требуют серьезных изменений функционала в коде Биткойна.
Value Shuffle - это протокол микширования монет на базе CoinJoin, реализуемый при помощи Confidential Transaction и Stealth Addresses.
В своей статье ниже, и о протоколе Value Shuffle, и небольшой итог моих исследований под тегом #Privacy. На этом я не остановлюсь и мы дальше продолжим знакомиться с протоколами конфиденциальности.
⬇️⬇️⬇️
https://teletype.in/@russiano55/ValueShuffleforBitcoin
#Privacy
Telegram
CryptoBotan
✅✅✅
Технологический стек биткоина (Update)
Несколько месяцев работы в этом посте. Как итог: визуализация масштабов экосистемы Биткойна и работы над ней.
Добавил от себя некоторые решения. Внутри ссылки на проекты и протоколы, статьи и посты из других…
Технологический стек биткоина (Update)
Несколько месяцев работы в этом посте. Как итог: визуализация масштабов экосистемы Биткойна и работы над ней.
Добавил от себя некоторые решения. Внутри ссылки на проекты и протоколы, статьи и посты из других…
Вернемся к теме #Privacy и сегодня про CoinJoinXT
Часть.1
⬇️⬇️⬇️
Напомню, CoinJoin предлагает возможность предоставлять входные данные для транзакций, для невозможности определения владения или контроля над выходными данными.
Как уже давно всем известно, классический CJ имеет ряд недостатков и упущений:
- если все участники CoinJoin не используют равные суммы, то можно определить какие входы, оплачивают выходы
- наблюдатель может определить, что это CoinJoin-транзакция, а следовательно, нарушается принцип взаимозаменяемости.
Анализ блокчейна подразумевает вероятностные предположения - эвристику. Подробнее в разделе “Блокчейн-атаки на приватность” на канале @bitcoin_translated
Эвристика 1 - все входные данные для транзакции принадлежат одной и той же стороне.
Эвристика 2-одноразовые адреса изменения принадлежат той же стороне, что и входные данные.
Также существует еще одна эвристика: "передача права собственности между сторонами в одной сделке подразумевает передачу права собственности"😐 Но я тоже не сразу въехал и об этом позже.
Adam Gibson, один из разработчиков JoinMarket, называет CoinJoin моделью "внутренней взаимозаменяемости", хоть и создаваемая транзакция распознается как CoinJoin, невозможно различить выходы, так как они равны.
Также он предлагает модель "отрицания", где транзакции взаимозаменяемы, но выглядят как обычные платежи. Такой способ он назвал CoinJoinXT.
Часть.1
⬇️⬇️⬇️
Напомню, CoinJoin предлагает возможность предоставлять входные данные для транзакций, для невозможности определения владения или контроля над выходными данными.
Как уже давно всем известно, классический CJ имеет ряд недостатков и упущений:
- если все участники CoinJoin не используют равные суммы, то можно определить какие входы, оплачивают выходы
- наблюдатель может определить, что это CoinJoin-транзакция, а следовательно, нарушается принцип взаимозаменяемости.
Анализ блокчейна подразумевает вероятностные предположения - эвристику. Подробнее в разделе “Блокчейн-атаки на приватность” на канале @bitcoin_translated
Эвристика 1 - все входные данные для транзакции принадлежат одной и той же стороне.
Эвристика 2-одноразовые адреса изменения принадлежат той же стороне, что и входные данные.
Также существует еще одна эвристика: "передача права собственности между сторонами в одной сделке подразумевает передачу права собственности"😐 Но я тоже не сразу въехал и об этом позже.
Adam Gibson, один из разработчиков JoinMarket, называет CoinJoin моделью "внутренней взаимозаменяемости", хоть и создаваемая транзакция распознается как CoinJoin, невозможно различить выходы, так как они равны.
Также он предлагает модель "отрицания", где транзакции взаимозаменяемы, но выглядят как обычные платежи. Такой способ он назвал CoinJoinXT.